-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Make AssocItem
aware of its impl kind
#145186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
rustbot has assigned @petrochenkov. Use |
Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in compiler/rustc_sanitizers cc @rcvalle changes to the core type system Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in compiler/rustc_passes/src/check_attr.rs This PR changes rustc_public cc @oli-obk, @celinval, @ouz-a Some changes occurred in compiler/rustc_codegen_ssa |
This comment has been minimized.
This comment has been minimized.
0617ff2
to
cfed1ee
Compare
This comment has been minimized.
This comment has been minimized.
cfed1ee
to
77a42ec
Compare
@@ -1258,7 +1258,10 @@ pub(crate) fn clean_impl_item<'tcx>( | |||
})), | |||
hir::ImplItemKind::Fn(ref sig, body) => { | |||
let m = clean_function(cx, sig, impl_.generics, ParamsSrc::Body(body)); | |||
let defaultness = cx.tcx.defaultness(impl_.owner_id); | |||
let defaultness = match impl_.impl_kind { | |||
hir::ImplItemImplKind::Inherent { .. } => hir::Defaultness::Final, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this should be None?
@bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Make `AssocItem` aware of its impl kind
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (ecc5941): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.4%, secondary -1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 3.3%, secondary 2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.3%, secondary 0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 463.257s -> 466.12s (0.62%) |
☔ The latest upstream changes (presumably #145210) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler/rustc_middle/src/ty/mod.rs
Outdated
self.assoc_parent(def_id).filter(|id| self.def_kind(id) == DefKind::Trait) | ||
self.opt_associated_item(def_id) | ||
.is_some_and(|assoc| assoc.container == AssocItemContainer::Trait) | ||
.then(|| self.parent(def_id)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fetching def_kind
is cheaper than opt_associated_item
, this change may contribute to the regression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I am making this same tradeoff in several places in the PR though and it seems to yield positive results on average. This has one less query in the case where it returns None due to the assoc container (Before: def_kind+parent+def_kind
. After: def_kind+associated_item
). I do see there is an increase in executions (not just hits) of associated_item
, so maybe there is a cost with executing that query on more items. I'm just not sure how to know which specific code change is causing that.
I looked at the cachegrind output and it looks like a large majority of the increased instructions are coming from llvm. I don't know what to make of that. I would have expected this PR to have no effect there. But that makes me think the regression cause is something surprising.
I could try splitting this PR into more incremental changes. Though most of the commits are co-dependent in some way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I targeted this change in particular because :
- def_kind is almost always already cached, and much cheaper to load,
- parent is not a query but just a table access.
But this is just a hunch, I made no measurement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
parent is not a query but just a table access
Oh! I misunderstood that. Okay, I'm going to look back over things with that in mind. I think you're right - I'll revert this change and maybe others.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def_kind is almost always already cached
Nit: not even "almost", it's always fed at DefId
creation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, now with a lower aversion to parent
😅 , I reverted some changes and changed / split out some changes into #145266.
@rustbot author |
Reminder, once the PR becomes ready for a review, use |
77a42ec
to
1d8ed9f
Compare
@rustbot ready (pending CI) |
@bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Make `AssocItem` aware of its impl kind
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (68df66d): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.4%, secondary -6.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (secondary -0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 464.993s -> 464.709s (-0.06%) |
The general goal is to have fewer query dependencies by making
AssocItem
aware of its parent impl kind (inherent vs. trait) without having to query the parent def_kind.enum hir::ImplItemImplKind::{Inherent, Trait}
atImplItem.impl_kind
which allowsImplItem
to be aware of its containing impl kind, and also move impl-kind-specific fields into corresponding variants.AssocItemContainer::Impl
intoAssocItemContainer::{InherentImpl, TraitImpl}
.AssocItemContainer
in numerous places.